The present invention relates to computer-implemented systems and methods for project management. More particularly, the present invention relates to improved computer-implemented techniques for facilitating collaborative project development and communication among the project participants.
The management of resources (e.g., time, people, materials or the like) and response to changes in the development of a large project has long presented many challenges to the project participants and the managers responsible for bringing the project to completion. Take for example the case of an automobile development project. Automobiles employ engines, which have cylinders that may need to be cast and honed prior to being assembled into the engine. In this very simple example, an automobile company X may engage a supplier Y, who supplies cast cylinders to automobile company X. Automobile company X may also engage a honing contractor Z, who is under contract to receive the cast cylinders from automobile company X and hone them to specification.
To ensure that the engine development portion of the project is on track, a manager in automobile company X may need to track the delivery of cast cylinders (in terms of quality, quantity, delivery date, or the like) from supplier Y. That manager may also need to set up a schedule to ship the cast cylinders received from supplier Y to honing contractor Z for honing. To ensure that the shipment of cast cylinders was not lost after being shipped out to contractor Z, that manager may also need to set up a separate schedule to conform, perhaps a few days after shipping, that honing contractor Z had indeed received the cast cylinders.
Automobile company X may wish to grant supplier Y access to the project management software, or at least to some portion of it, so that supplier Y can tick off its own action item (e.g., shipping a quantity of cast cylinders to automobile company X on a certain date). Such access by supplier X is beneficial since an employee in automobile company X may wish to be notified of the shipment in order to ready the quality control group for inspecting the incoming cast cylinders and/or to notify honing contractor Z of the upcoming honing order.
Likewise, automobile company X may also wish to grant honing contractor Z access to the project management software, or at least some portion of it, so that honing contractor Z can receive information pertaining to when and how many of the cast cylinders were actually shipped to him from automobile company X so that contractor Z can more efficiently manage its resources to service the honing order (such as to arrange to rent honing equipment in anticipation of the arrival of the cast cylinders). Such access by honing contractor Z would also benefit automobile company X since honing contractor Z may in turn be able to use the project management software to notify the interested employees within automobile company X of the honing progress, whether and when the honed cylinders were shipped back to automobile company X, and so forth. Honing contractor Z may also want to have the ability to inform to automobile company X, or the employees of automobile company X that are interested in the honing process, that it has perfected a new honing technique and may be able to hone to a closer tolerance if automobile company X can extend the deadline for the delivery of honed cylinders by a few weeks. All these communications are preferably implemented in a single software package to facilitate record keeping and integration with progress tracking.
Communication among the project participants (such as the employees of company X, supplier Y, and honing contractor Z in this example) may be complicated by some real world, practical considerations. For example, automobile company X may prefer, due to confidentiality considerations, that honing contractor Z do not know about the price paid by automobile company X to a competing honing contractor, or to casting supplier Y.
Although the above scenario is discussed in some detail to illustrate some challenges and requirements that may be present when managing a complex project, such a scenario is very simplistic. In the real world, it is not uncommon for a project to require dozens or hundreds of geographically remote participants, each contributing to a portion of the project at various time periods, and many of whom need to work and communicate collaboratively if the project is to be completed timely and efficiently.
In the current art, there exist many types of software programs that may be employed for project management. By way of example, Gantt charts, in either the hardcopy version or the software version, have long been employed by project managers to track tasks and dates relevant to a particular project. To facilitate discussion, FIG. 1 illustrates a Gantt chart 100, including thereon bars representing tasks and deadlines. Although only a few tasks are shown on Gantt chart 100, it should be kept in mind that the example has been vastly simplified to facilitate discussion. In reality, a typical real world Gantt chart may involve thousands or tens of thousands of tasks and may very well fill an entire wall, or even more, if displayed on paper.
On Gantt chart 100, bars 102 and 104 represent the major tasks that need to be undertaken. Bar 102 may represent, for example, the cylinder development phase, and bar 104 may represent, for example, the engine assembly phase. A dependency line 106 connects the end of bar 102 to the beginning of bar 104, signifying the fact that cylinder development has to be completed before engine assembly can begin. A milestone 108 marks the completion of the engine assembly phase.
A major task such as cylinder development may be subdivided into subtasks. Gantt chart 100 tracks these subtasks by the use of subtask bars, such as bars 112 and 114 under cylinder development task bar 102. Bar 112 may represent, for example, the subtask of obtaining cast cylinders, and bar 114 may represent, for example, the subtask of getting the cylinders honed. Subtasks may also have relationships, one of which is illustrated in FIG. 1 by a dependency line 116. Dependency line 116 connects the end of bar 112 to the beginning of bar 114, signifying that cylinder honing can not begin until after the cylinders are casted.
Although Gantt charts, both on paper and in their software versions, have been employed successfully in bringing many projects to completion, there are disadvantages. By way of example, one of the weaknesses of the traditional Gantt chart approach is the inability to allow a project participant to easily filter through the voluminous data related to a project in order to focus in only on data and/or deadlines that are relevant to that particular user in a specified time period. Take for example the case of an employee of automobile company X, who are involved in or interacting with multiple departments (e.g., cylinder development, clutch ordering, paint testing, etc.). The traditional Gantt chart approach does not allow this employee to easily find out, for example, what action items he needs to take on a specified day or a specified week across the multiple departments involved.
A Gantt chart typically deals with only tasks (and subtasks), the task commencement dates, and deadlines. During a project, they are many times when a project participant needs to communicate different types of information, other than tasks and dates, with other project participants. By way of example, a project participant may wish to employ the project management software to communicate to those interested that a new piston design has been selected and also include a drawing of the newly designed piston in the communication. The redesign of the piston may impact those in cylinder design (including our supplier Y and honing contractor Z). However, the typical Gantt chart does not provide a facility to allow project participants interested in or impacted by the piston design change to be alerted of this fact, to view the new piston design, to determine how their own delivery schedule may be impacted, and to communicate their concerns with other project participants (e.g., the manager in charge of engine assembly, who depends on timely delivery of finished components to perform his job). Without these communication facilities, project participants must switch to other communication modalities outside of the project management software environment to communicate, e.g., switch to email, phone, facsimile, or the like. When that happens, it becomes very difficult to centralize record keeping of the communications and/or integrate the communications with progress tracking.
Still further, the typical Gantt chart does not readily provide a way for a project participant to track the actual performance on a particular task (e.g., the number of cylinders actually honed) and compare the actual performance with the expectation in order to generate a notification or an alert. Still further, there are times when an explanation or a comment would be helpful to clarify to other project participants why a data item is modified (such as when the piston design is changed). By way of example, it may very well be the case that the change in piston design was made to allow the use of less expensive and more readily available cylinders that the piston group knew about. Without this annotation capability, however, project participants such as the employees in the cylinder development group may be aware only of the piston design change and may respond by undertaking expensive cylinder design changes unless someone in the piston design group remembers to use another forum of communication (e.g., email, phone, facsimile, or the like) to inform the cylinder design group of the ready availability of the suitable cylinders.
Collaborative Gantt charts also suffer many of the aforementioned disadvantages. By way of example, a typical collaborative Gantt chart also does not readily provide a way for a project participant to filter through vast amount of data in order to focus in on items, data, or dates that are relevant to that particular project participant. Likewise, there is usually no facility with which a project participant can easily ask the typical collaborative Gantt chart software to compare the actual performance versus the expected performance of a trackable item in order to generate a notification or a warning. Typical collaborative Gantt charts also lack the aforementioned annotation capability, making it difficult for project participants to communicate the reasons or explanation behind the data.
Collaborative spreadsheets represent another class of software programs that have been employed to facilitate collaborative project development. In a collaborative spreadsheet, the data pertaining to the items to be tracked are stored in cells, which are arranged in a matrix arrangement and are accessible to the project members. Collaborative spreadsheets, however, also have disadvantages. By way of example, the typical collaborative spreadsheet also does not readily provide a way for a project participant to filter through vast amount of data in order to focus in on items, data, or dates that are relevant to that particular project participant. Further, the cell structure is fairly limiting in that each cell typically tracks only one value of one type of data (e.g., text, number, date, and the like). If a trackable event involves multiple values that need to be monitored simultaneously (e.g., both date and quantity), the cell of a typical collaborative spreadsheet does not accommodate such a requirement well.
A typical collaborative spreadsheet cell also lacks the ability to track the change in the cell""s value over time. By way of example, the delivery date of the honed cylinders may be revised many times during the project, due to problems encountered by honing contractor Z or due to events outside of his control (such as late receiving of the raw cast cylinders). Unless a history is kept of the change, it would be difficult for the cylinder development manager to go back in time to audit the changes and find out when the date was changed, by whom, and perhaps why. Also, the matrix-like architecture of a typical spreadsheet makes it difficult to partition groups of cells to implement access control.
In view of the foregoing, there are desired improved computer-implemented techniques for facilitating collaborative project development and communication among the project participants during a project.
In accordance with one aspect of the present invention, there are provided computer-implemented systems and techniques for facilitating collaborative project development and communication among project participants across people, time, and space. In one embodiment of the present invention, there is provided a collaborative project management environment based on computer-implemented constructs known as trackpoints, whose flexible construct permits substantially any type of trackable item or communication to be stored therein. Unlike the single-attribute cell of the prior art collaborative spreadsheet model, a trackpoint can simultaneously track multiple attributes and functions that employ attributes as arguments, can be annotated with multimedia content, and can be represented by metadata (which is descriptive of the trackpoint, its genesis, and/or its evolution) for indexing and searching purposes. A trackpoint can also explicitly or implicitly reference other trackpoints, thereby facilitating the establishment of arbitrary project teams from the common database of trackpoints pertaining to the project.
Using a plurality of tools which take advantage of the architecture of the inventive collaborative project management and communication software, the flexible construct of the trackpoints, the annotation capabilities of the trackpoints, and the indexed metadata, a project participant can author (i.e., create or modify) a trackpoint, can freely and efficiently search for data that is of particular interest to that project participant, can send and/or receive communication through text, drawings, annotations, markups on text/graphics, multimedia content, and other types of data, and can even request to be notified upon the occurrence of certain events. Furthermore, the project participant can advantageously create a customized and/or filtered view that focuses in only on the data relevant to that user, irrespective of whether that data comes from a single trackpoint, from multiple trackpoints, or even multiple trackpoints that are created at different times and by different functional groups of the project.
These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various drawings.